In a communication system where a control device integrally controls forwarding node(s) for carrying out communication, the forwarding node(s) and the control device must be synchronized with each other. This is because, if the control device and the forwarding node(s) are not synchronized, a packet-forwarding method instruction transmitted from the control device to a forwarding node becomes inconsistent with the packet forwarding processing performed by the forwarding node, with the result that the packet forwarding not intended by the control device is performed.
As a communication system where the control device integrally controls the forwarding node(s) as described above, the technology called OpenFlow is known (see Patent Literature 1 and Non-Patent Literatures 1 and 2). OpenFlow identifies communications as end-to-end flows and performs path control, failure recovery, load balancing, and optimization on a per-flow basis. An OpenFlow switch, which is specified in Non-Patent Literature 2, has a secure channel for communication with an OpenFlow controller that serves as a control device, and operates according to the flow table to which information is added, and whose contents are rewritten, according to an instruction from the OpenFlow controller as necessary. In the flow table, a set of the following three is defined for each flow: a matching rule (Header Fields) against which a packet header is matched, flow statistical information (Counters), and an action(s) (Actions) that defines processing contents (see FIG. 18).
For example, when a packet is received, the OpenFlow switch searches the flow table for an entry that has a matching rule (see Header fields in FIG. 18) that matches the header information of the received packet. If an entry matching the received packet is found as a result of the search, the OpenFlow switch updates the flow statistical information (Counters) and, at the same time, performs the processing contents (packet transmission from a specified port, flooding, drop, etc.), described in the Actions field of the entry, for the received packet. On the other hand, if an entry matching the received packet is not found as a result of the search, the OpenFlow switch forwards the received packet to the OpenFlow controller via the secure channel, requests the OpenFlow controller to determine a packet path based on the transmission source/destination of the received packet, receives a flow entry for the packet path, and updates the flow table. In this way, the OpenFlow switch forwards a packet using an entry, stored in the flow table, as the processing rule.
However, Patent Literature 1 and Non-Patent Literatures 1 and 2 described above do not include a practical study on how to confirm the synchronization between the OpenFlow controller and the OpenFlow switch.
In addition, Patent Literature 2 discloses the technology for confirming if data held in a mobile device and data stored in the database to which the mobile device is connected are synchronized. According to this literature, a mobile device generates a hash for each piece of data held in the mobile device and transmits the generated hash to the synchronization server to request it to confirm if the data is synchronized. The synchronization server generates a hash for each piece of data for which synchronization confirmation is requested. The synchronization server compares a plurality of hashes, transmitted from the mobile device, with a plurality of hashes generated by the synchronization server. The synchronization server confirms data synchronization based on the comparison result. The literature describes that the bandwidth required for synchronization may be reduced by generating a hash from each of multiple data pieces, for which synchronization confirmation is required, and by performing synchronization confirmation.